Users have an increasing need to dynamically prioritize the individual traffic flows of application sessions traversing IP (Internet Protocol) based networks, such as enterprise networks and VPN-type services provided by Internet Service Providers. An application session, for the purposes of this discussion, is a connection between any given instance of a client application and a server application, wherein the session comprises one or more individual traffic flows. The need to prioritize traffic flows exists because networks are carrying increasingly diverse traffic types that all compete for network resources. When a given traffic flow has particular bandwidth, latency, and packet loss requirements (i.e., particular quality of service (QoS) needs), other network traffic can consume network resources and thereby adversely affect the flow. Network administrators will typically use Diff Serv (differentiated services) enabled networks to allocate network resources to critical applications so that the performance needs of these application sessions are met.
Specifically, a Diff Serv enabled network allows heterogeneous traffic types from different application sessions to co-exist while at the same time allocating these varying traffic types different network resources based on the needs of the application. As indicated, some traffic types have bandwidth, latency, and packet loss requirements that the total mix of traffic on a network can adversely affect. Diff Serv allows a network administrator to establish traffic classes in the network by allocating network resources to each class. (In general, traffic classes are established by configuring the network routers to support varying packet queuing and forwarding techniques and thereby providing different throughput, latency, and loss services for each class). Application sessions are then assigned to these classes and are thereby generally able to receive a certain quality of service.
Traffic classes are not specific to any given user, application, or session. Rather, any given traffic class will typically carry data packets from many different applications originating from many different users. In particular, edge routers of the network (or a dedicated hardware coinciding with the router) assign packets from application sessions to traffic classes. The edge routers analyze each packet as it enters the network, classifying the packet according to an assigned traffic class, and insert a specific Differentiated Services Code Point (DSCP) value in the DSCP field of the packet based on the assigned traffic class. The network routers use a packet's DSCP value to process the packet according to the assigned traffic class. The edge routers also typically condition the traffic before forwarding it into the network. Traffic conditioning includes packet shaping, dropping, and policing. Policing ensures that any given application session does not utilize more bandwidth than associated with the assigned service. Importantly, for edge router performance reasons, the network administrator typically configures the edge routers to assign traffic flows to traffic classes on an application and site basis. In other words, all traffic flows from a given application session from a set of designated sites are assigned to the same traffic class.
Although the traditional approaches to Diff Serv can provide critical applications with the required resources to the meet the application needs, these approaches have several drawbacks. In particular, there are an increasing number of application sessions that users want to prioritize. At the same time, however, very often only a particular traffic flow from a given session requires prioritization. Similarly, users often want to dynamically decide when a given application session receives prioritized service and when it does not. However, typical Diff Serv approaches are not sufficiently scalable and dynamically configurable to meet the increasing number of applications sessions and individual user needs. Another issue is that Diff Serv approaches are often susceptible to unpredictable traffic loads.
More specifically, the assignment of application sessions to traffic classes is static under Diff Serv. Once a network administrator configures the edge routers to mark specific application packets, all application sessions for that application from a set of designated sites are assigned to the given traffic class and these configurations are essentially static. This is problematic because in any given instance, a user may decide that a given application session requires the services of a particular traffic class and the network administrator has not configured the edge routers to assign that user to the class or, similarly, may not have assigned that given application to a traffic class. In addition, users often determine that a given session does not require the services of a given traffic class or requires a higher service. One solution to these issues is for a user to dynamically contact the network administrator for reconfiguration of the edge routers on a per need basis. However, this is both time-consuming and unusable from a user perspective and unfeasible from an administrative perspective.
A similar issue is that the network resources are limited. Accordingly, administrators must take care when configuring the edge routers to not over admit application sessions/users to the traffic classes. However, not all admitted users simultaneously run application sessions, which results in administrators essentially underestimating the number of application sessions that should be allowed access to a traffic class and thereby under-utilizing the network resources. Similarly, it is usually only a given traffic flow within a given session that actually requires the services, causing traffic classes to often carry unnecessary data packets. Accordingly, administrators should allocate network resources on a per-traffic flow basis and when specifically needed. Again, such a system is time consuming and unusable from a user perspective and unfeasible from an administrative perspective. In addition, such continuous/dynamic assignment of traffic flows to traffic classes is not scalable, which is further described below.
Similar issues exist in network environments where IP addresses are dynamically assigned through DHCP (Dynamic Host Configuration Protocol) and therefore dynamically change. In this environment, network administrators are required to constantly reconfigure the edge routers as IP addresses are re-assigned to network users or are forced to assign applications to traffic classes at a more coarse level, disregarding the individual sites. Again, quality of service is more appropriately designated on a per user/application session level.
A second issue with traditional Diff Serv approaches is that they are not scalable. On a fundamental basis, as more users are added to a network and/or as administrators increase the number of applications requesting traffic class services, the edge routers correspondingly must perform additional packet filtering/marking/conditioning/policing responsibilities. At some point, the functional ability of the edge routers is reached, thereby causing the administrators to have to add additional edge routers to the network at additional cost. Similarly, as the edge routers are configured to admit more application sessions, the internal network resources must also be increased. However, as described above, the number of application sessions simultaneously needing the network resources is usually less than the number the edge routers are configured to admit, thereby causing network administrators to over provision the network.
Similarly, as described above, quality of service is more appropriately designated on a dynamic user basis at the traffic flow level. Again, edge router performance issues will occur if routers are made to mark and condition at the traffic flow level, especially as users and applications are added to the network. In addition, continuously configuring and reconfiguring edge routers on a per user basis compromises edge router performance.
A third issue with the traditional Diff Serv approaches is admission control. Typically, when configuring network resources to establish traffic classes, an administrator approximates the number of instantaneous application sessions that will occur and the traffic classes each should be assigned to. As long as the number of simultaneous application sessions for a given traffic class does not exceed the configured approximation, each session will receive adequate resources. However, an unexpected number of sessions for a given traffic class can occur, which results in performance degradation across the class causing no session to receive adequate resources. One solution to this is to over-provision the traffic class, but this wastes network resources.
Prior solutions have only partially addressed the above issues, including systems referred to as bandwidth broker systems. A bandwidth broker is a network management system that provides admission control and bandwidth management for Diff Serv enabled networks by tracking the amount of bandwidth being used in each traffic class. When an application session requires the services of a traffic class, the application makes an admission request to the bandwidth broker, providing the bandwidth and the traffic class being requested. The bandwidth broker determines whether sufficient bandwidth is available in the respective traffic class. If there is sufficient bandwidth, the bandwidth broker decreases the amount of available bandwidth for the traffic class, and configures the appropriate edge router to mark, condition, and police the new traffic. Otherwise the new session is denied admission.
Advantageously, bandwidth broker systems prevent traffic classes from becoming over-utilized thereby preventing performance degradation; they allow for dynamic/automatic application controlled QoS management; and, they allow for better utilization of internal network resources. However, the systems have several disadvantages. First, bandwidth broker systems fail to address the scalability issues described above. While these systems are suitable for small-scale networks, edge routers are not capable, from a performance perspective, of marking/conditioning/policing numerous application sessions or worse, traffic flows, and are compromised as users increasingly make numerous configurations/reconfigurations on a dynamic basis. A second issue is that applications must be specifically designed/programmed to communicate with bandwidth broker systems and, as such, applications are not easily integrated into the framework making bandwidth broker systems difficult to use. More specifically, an application developer must understand the low-level detailed traffic attributes of the application sessions the application will generate and translate these attributes into one of the traffic classes supported by the network so that the actual traffic class request can be made to the bandwidth broker. This issue becomes worse if an application session needs to traverse several networks, each with different traffic classes and managed by different bandwidth brokers. Here, the application developer must make the traffic-attributes to traffic-class translation for each network/bandwidth broker. In addition, the developer must determine which networks a given session will traverse in order to communicate with the appropriate bandwidth brokers.